home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000117_icon-group-sender _Thu May 27 06:31:18 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  5KB
  1. Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 27 May 1993 07:32:45 MST
  2. Received: by owl.cs.arizona.edu; Thu, 27 May 1993 07:32:44 MST
  3. Date: 27 May 1993 06:31:18 -0600 (CST)
  4. From: Chris Tenaglia - 257-8765 <TENAGLIA@mis.mcw.edu>
  5. Subject: Comparative Languages (MUMPS?)
  6. To: icon-group@cs.arizona.edu
  7. Message-Id: <01GYNRS810XE8WW871@mis.mcw.edu>
  8. Organization: Medical College of Wisconsin (Milwaukee, WI)
  9. X-Vms-To: IN%"icon-group@cs.arizona.edu"
  10. Mime-Version: 1.0
  11. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  12. Content-Transfer-Encoding: 7BIT
  13. Status: R
  14. Errors-To: icon-group-errors@cs.arizona.edu
  15.  
  16.  
  17. Icon  seems  to  incorporate  some of the best features of the best computer
  18. languages. It has probably exhausted it's grant money for further renovation
  19. but  I've  been  putzing  with  another  kind  of  string  language. This is
  20. something Hospitals use extensively, namely MUMPS.
  21.  
  22. I  sat  with  a  MUMPS guru for about an hour back in December and heard the
  23. party  line,  and  asked  him  certain language design questions. MUMPS also
  24. makes  the  Icon  claim of very quick development. It seemed to have all the
  25. functionality of Icon but in a very different form.
  26.  
  27. MUMPS like Icon is designed around a virtual machine and has an interpreter,
  28. compiler,  X-windows,  easy  types,  automatic memory management and garbage
  29. collection.
  30.  
  31. But the part that I think is really cool is an architecture independent file
  32. system.  My  understanding  is  probably  a  little  warped,  but  here's my
  33. understanding  of  MUMPS  data.  It  comes  in  3  forms. LOCAL, GLOBAL, and
  34. STRUCTURE.  LOCAL  are  your  local variables, and procedures that disappear
  35. after  the  running program finishes. STRUCTURES are builtin data structures
  36. offered  by  the  operating  system. GLOBALS are handled like variables, but
  37. they're  actually  files, well sort of. They are files in that they don't go
  38. away  after  the  program is done, or you log out. You don't have to open or
  39. close  them,  they're  just there. All you have to do is reference them. The
  40. cool  part  is that they can be complex data like icon lists, and tables and
  41. procedures  (programs).  There  is  a  programmer  and user environment. The
  42. programmer  environment  can  step through programs, use breakpoints, or run
  43. single  expressions  interactively.  The  user  environment is tight with no
  44. programming access.
  45.  
  46. MUMPS  provides  facilities  to  read  and write to file systems and devices
  47. outside  it's  environment. While it can be used this way, I get the feeling
  48. these  are  designed  for  you to import your data into the environment, and
  49. export it to non-MUMPS environments.
  50.  
  51. Here is a sample of what Icon might be like using a MUMPS global paradigm.
  52.           
  53.           procedure main()
  54.           In := open("external.dat")          # to import from outside
  55.           $Reference := table(0)              # $ maps Reference to a file
  56.                                                 available to all icon
  57.                                                 programs by name $Reference.
  58.           while Line := read(In) do           # in fact, the table is not
  59.             {                                 # initialized here, but just
  60.             Name := Parse(Line,' ')[1]        # declared for access. Old
  61.             Adrs := Parse(Line,' ')[2]        # contents still remembered
  62.             $Reference[Name] := Adrs          # but the init value might
  63.                                                 be different in different
  64.                                                 procedures.
  65.             }
  66.           close(In)
  67.           end
  68.           
  69. Later,  this  is  run  and  $Reference  is populated with data. Since it was
  70. loaded  as a filed variable, a later program can reference it already loaded
  71. and in the table associative array mode.
  72.  
  73.           procedure main()
  74.             $Reference  := table(0)    # maps in the data
  75.             every Check := !Occurence do Crunch($Reference[Check])
  76.             end
  77.  
  78. A  list  or  set like structure could be initialized in this method too. Any
  79. comments  concerning  having  some  variables  or types directly map to file
  80. system  structures that are non-volatile from session to session? I think it
  81. helps  because you don't have to clutter your code up with all kinds if open
  82. close  and  testing statements. Open and close would be used for exporting &
  83. importing data, manipulating pipes and x-windows.
  84.  
  85. Chris Tenaglia (System Manager) |  "The past explained,     
  86. Medical College of Wisconsin    |   the future fortold, 
  87. 8701 W. Watertown Plank Rd.     |   the present largely appologized for."
  88. Milwaukee, WI 53226             |   Organon to The Doctor
  89. (414)257-8765                   |     
  90. tenaglia@mis.mcw.edu
  91.